Databases, such as those provided by ORACLE, are used to support applications, such as applications for depositing checks, processing bank loans, and transferring funds. The applications may be executed on computers of companies, such as banks, and their customers. The databases store information needed by the applications to perform their functions. An application may send a request for information to a database. In turn, the database may request the information from a shared storage array. A service level agreement (SLA) may be in effect to control/manage the transfer of information between the database and the shared storage array. For example, the SLA may set limits/restrictions, referred to as service level objectives, on an amount/size of the information being transferred and the frequency at which transfers take place.
If SLOs are exceeded, a latency issue may arise. As latency increases, the database memory may become full and the database may become overloaded/throttled. This may also cause the application to run slower, and a user of the application may experience a frozen screen or other sign of buffering. There are tools for monitoring databases, but the tools are commonly not helpful for identifying the cause of an overloaded/throttled database. In particular, the tools do not provide storage throughput data in small enough intervals to allow troubleshooters to identify the problem and do not make it readily apparent which part of the database is causing the problem.
In light of the above, it should be understood that there may be a demand, for example, among organizations (e.g., banks), their personnel (e.g., troubleshooters and database administrators), and others (e.g., contractors) responsible for troubleshooting databases, for equipment/devices, methods, software, and systems that assist in monitoring database storage so that problems, and the parts of the database that cause them, may be readily identified.